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ir^^inception,  the  Department 
of  ■^tense's  development  of 
acfllisition  policies  and  guid- 
anH  has  been  focused  on  the 
cWation  and  deployment  of 
Traditional  weapons  systems— 
such  as  planes,  ground  vehi¬ 
cles,  and  ships— in  support  of 
the  warfighter.  Some  may  see 
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Treating  IT  programs  in 
an  "out  of  sight,  out  of 
mind"  manner  with  no  real 
dedication  of  time  and 
attention  to  the  problems  is 
not  the  answer  in  the  face 
of  changing  technology  and 
adversity. 


the  existing  DoD  process  for  acquiring  those  systems  as 
complex;  however,  the  current  procedures,  as  outlined  in 
DoD  Instruction  5000.02,  offer  a  more  defined  approach 
for  weapons  systems  acquisition  than  for  the  acquisition  of 
information  technology  systems.  The  current  DoDI  5000.02 
leaves  IT  project  and  program  managers  wondering  how  the 
current  process  applies  to  them,  as  the  guidance  is  fairly  rigid 
and  does  not  allow  for  the  flexibility  required  to  appropriately 
manage  IT  programs. 

Until  very  recently,  in  comparison  to  the  development  of  a 
traditional  weapons  system,  IT  programs  seemed  to  have 
been  viewed  as  a  utility  or  service  instead  of  a  critical  com¬ 
ponent  to  national  security.  Perhaps  that  is  because  data 
passing  through  cables  cannot  be  observed  with  the  naked 
senses  and  therefore  an  "out  of  sight,  out  of  mind"  philos¬ 
ophy  is  applied  when  it  comes  to  policy  and  guidance.  It 
seems  as  though  managers  and  decision  makers  who  are 
not  familiar  with  IT  take  the  stance  of  "I  don't  understand  it, 
just  make  it  work." 

At  a  recent  conference,  military  leaders  admitted  that  they 
did  not  completely  understand  the  role  of  IT  in  operations; 
however,  with  so  much  attention  being  brought  to  the  issue, 
that  may  be  changing.  Operational  commanders  are  now 
realizing  that  they  have  a  real  need  to  understand  IT  as  it 
affects  operations  and  the  decisions  regarding  IT  that  are 
being  made  by  others.  As  with  weapons  systems,  the  so¬ 
lution  for  IT  acquisition  program  managers  is  to  tailor  the 
DoDI  5000.02  to  their  perspective  programs.  That  does 
not,  however,  address  the  three  major  issues  associated 
with  information  technology  programs:  the  rate  of  techno¬ 
logical  improvements  in  capability,  the  processes  for  both 
acquiring  and  fielding  new  IT  components,  and  funding  for 
IT  programs. 


Information  Technology  Acquisition 
Challenge 

By  far,  the  biggest  challenge  to  IT  programs  is  the  rate  at 
which  technology  changes.  Ray  Kurzweil,  in  his  essay  "The 
Law  of  Accelerating  Returns,"  builds  on  Moore's  Law  (expo¬ 
nential  growth  in  the  number  of  transistors  per  integrated 
circuit)  to  describe  what  he  calls  the  exponential  rate  of 
technological  change.  In  fact,  Kurzweil  goes  on  to  suggest 
that  the  rate  of  technological  growth  is  itself  growing  expo¬ 
nentially.  That  is  clearly  demonstrated  when  one  considers 
the  Internet.  Until  the  early  1990s,  the  Internet  didn't  exist 
in  its  current  form.  Since  that  time,  there  have  been  tremen¬ 
dous  improvements  in  technologies  and  capabilities  for  the 
Internet. 

As  IT  develops  in  the  commercial  market,  new  capabilities 
are  generated  in  a  matter  of  months.  DoD  is  not  isolated 
from  this  changing  environment,  as  the  department  is  heav¬ 
ily  reliant  on  commercially  available  software  and  hardware. 
As  a  result,  there  are  challenges  in  maintaining  support  for 
older  software  and  hardware  products,  obstacles  to  over¬ 
come  with  the  procurement  of  new  products,  and  the  sub¬ 
sequent  integration  into  defense  systems.  Most  of  the  time, 
those  are  not  insignificant  or  superfluous  enhancements  to 
performance.  As  new  technology  emerges,  older  technol¬ 
ogy  becomes  obsolete,  seemingly  overnight,  and  users  usu¬ 
ally  want  the  latest  technology,  either  due  to  an  increase  in 
functionality  or  as  a  requirement  to  patch  a  discovered  vul¬ 
nerability,  cyber  threat,  or  incompatibility  created  by  other 
emerging  capabilities. 

For  example,  The  Wall  Street  Journal  reported  recently  that 
insurgents  were  able  to  gain  access  to  video  feeds  provided 
by  U.S.  military  unmanned  aerial  vehicles  using  a  soft¬ 
ware  package  that  was  publicly  available.  That  presented 
an  emerging  threat  as  the  insurgents  were  able  to  use  the 
technology  to  their  advantage  and  gain  access  to  critical  in¬ 
formation.  As  a  result  of  that  threat,  users  initiated  a  new 
requirement  to  secure  the  transmission  of  data.  This  single 
example  demonstrates  that  the  rate  of  change  to  technol¬ 
ogy  and  its  availability  become  forces  of  change  in  many 
defense  programs. 

The  rapid  rate  of  changes  in  technology  further  compli¬ 
cates  an  already  complex  acquisition  process  from  the  very 
first  step— the  definition  of  requirements.  DoDI  5000.02 
requires  a  fixed  set  of  requirements  prior  to  proceeding 
through  the  process.  Those  fixed  requirements  feed  into 
the  acquisition  process— a  process  that  typically  takes  a 
long  time  to  develop  into  a  system.  As  already  noted,  once 
a  requirement  has  been  defined,  it  is  only  a  short  matter 
of  time  before  that  requirement  becomes  obsolete  either 
because  of  advancement  in  technology  or  a  discovered  vul¬ 
nerability  that  requires  it  to  be  replaced  or  modified.  Under 
DoDI  5000.02,  that  leads  to  unplanned  costs,  requirements 
growth,  and  systemic  issues  associated  with  modifying  re¬ 
quirements  during  the  acquisition  process. 
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Obsolescence  is  an  issue  that  is  problematic  for  weapons 
systems  as  well;  however,  replacing  a  few  obsolete  compo¬ 
nents  on  a  weapons  system  is  very  different  from  having 
an  entire  system  that  is  made  up  of  components  that  face 
repetitive  obsolescence.  That  is  one  reason  requirements 
tend  to  remain  in  a  state  of  fluctuation  in  many  IT-intensive 
programs. 

Taking  a  stance  of  demanding  firm,  fixed  requirements  that 
stay  relatively  static  over  a  two-to-five  year  period  is  unreal¬ 
istic  with  IT-intensive  programs.  Thus,  a  change  in  mindset 
along  with  an  acquisition  process  that  anticipates  that  there 
will  be  ever  changing  requirements  is  needed. 

Rapid  Change  and  Undefined  Processes 

Development,  deployment,  and  operational  processes 
surrounding  IT  programs  need  to  be  considered  given  the 
dynamic  nature  of  technology.  A  lack  of  defined  processes 
supporting  an  IT  program  at  the  program,  component,  or 
Service  level  can  lead  to  challenges  for  a  program  manager, 
resulting  in  significant  delays,  cost  overruns,  and  perfor¬ 
mance  problems  in  the  program. 

Beginning  with  the  most  fundamental  function  of  contract¬ 
ing,  rapid  and  frequent  changes  require  that  a  well-written 
contract  be  in  place  for  those  types  of  programs.  If  the  pro¬ 
gram's  contract  is  not  well  written,  most  improvements  in 
capability  will  be  deemed  new  requirements  and  have  to 
undergo  a  contract  modification  process.  A  modification 
process  can  be  problematic,  as  the  negotiations  for  a  bi¬ 
lateral  modification  can  take  a  great  deal  of  time.  Further¬ 
more,  by  the  time  negotiations  are  completed,  the  product 
or  capability  being  acquired  can  be  obsolete  due  to  emerg¬ 
ing  technological  developments.  Contracts  for  IT  need  to  be 
well  written  to  accommodate  the  rapid  rate  of  technologi¬ 
cal  advancements,  and  contracting  modification  processes 
need  to  be  flexible  and  streamlined  so  as  to  not  impede  the 
timeliness  in  which  the  new  technology  can  be  implemented. 
For  example,  identify  those  things  that  are  likely  to  change 
rapidly  and  have  a  predetermined  method  of  getting  them 
on  the  contract.  That  can  be  done  via  a  contract  line  item 
number  that  encompasses  peripheral  devices,  for  instance, 
where  the  contract  line  item  number  doesn't  change  but  the 
devices  do  change  with  upgrades  to  them. 

Another  process  that  needs  to  be  considered  is  the  systems 
engineering  process.  As  described  earlier,  obsolescence  of 
software  and  hardware  becomes  a  challenging  issue.  Fre¬ 
quent  updates  in  technology  require  a  mechanism  to  si¬ 
multaneously  support  multiple  baselines  until  updates  can 
be  completed  as  well  as  support  the  upgrading  or  updating 
process  itself. 

As  an  example,  consider  the  number  of  computers  in  DoD 
that  currently  operate  using  the  latest  version  of  the  Micro¬ 
soft®  operating  system.  Now  imagine  that  Microsoft  decides 
to  no  longer  support  the  existing  version  of  its  operating 


system— this  frequently  happens  because  the  driving  force 
behind  Microsoft's  profitability  is  the  commercial  market. 
With  every  new  release  of  operating  system,  patch,  etc. ... 
all  of  the  computers  in  DoD  will  need  to  be  upgraded  with 
the  latest  product  available  exclusively  from  Microsoft.  In 
large  IT  programs,  that  could  mean  upgrading  hundreds  of 
thousands  of  computers  within  a  specified  timeline.  Upgrad¬ 
ing  a  single  component  or  piece  of  software  can  cause  un¬ 
foreseen  compatibility  and  interoperability  problems  in  the 
system  and  with  its  legacy  systems.  I  n  order  to  prevent  those 
problems,  it  is  necessary  to  have  a  sound  systems  engineer¬ 
ing  and  testing  process  before  a  change  of  this  magnitude 
is  implemented. 

Users  are  also  impacted  by  technology  refresh  as  it  can  be 
very  disruptive  to  their  normal  work  routine.  Users  have  to 
learn  how  to  use  the  new  technology  and  possibly  change 
how  they  previously  performed  their  tasks.  Therefore,  tech¬ 
nology  refresh  can  be  considered  a  taxing  event  for  everyone 
involved.  Also,  if  the  users  are  all  co-located  at  an  operational 
command,  the  upgrade  may  negatively  impact  a  command's 
ability  to  perform  its  mission.  Thinking  ahead  about  the  pro¬ 
gram's  strategy,  having  a  good  systems  engineering  process, 
developing  a  well-thought-out  technology  refresh  process, 
and  obtaining  stakeholder  support  for  the  process  are  criti¬ 
cal  for  success. 

Of  course,  one  has  to  discuss  the  impacts  of  information  as¬ 
surance  when  discussing  an  IT-intensive  program  or  project. 
This  is  yet  another  process  area  that  requires  a  very  through 
strategy  and  plan  and  stakeholder  support.  The  personnel 
involved  in  approving  the  system's  security  and  authority 
to  operate— like  the  Service-specific  designated  approval 
authorities— are  typically  not  part  of  the  program  or  project, 
and  that  creates  a  very  time-consuming  process  with  limited 
resources. 

There  are  many  things  that  can  be  done  to  streamline  the 
approval  process,  some  of  which  have  been  successfully 
implemented  in  other  major  automated  information  systems 


A  vision  for  IT  is  needed  at 
the  DoD  enterprise  level 
that  translates  to  a  Service 
perspective  and  moves  down 
to  the  individual  program 
office. 
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programs.  For  example,  prior  to  seeing  the  actual  author¬ 
ity  to  connect  a  request,  the  designated  approval  authority 
can  ensure  that  one  of  its  stakeholders  is  present  during 
testing  of  the  system,  upgrade,  or  patch,  ensuring  that  the 
representative  understands  what  the  device  is  and  its  vulner¬ 
abilities.  Embarking  on  the  development  and  fielding  of  an 
IT-intensive  system  without  early  coordination  and  coopera¬ 
tion  of  those  representatives  has  the  potential  to  delay  the 
program's  objectives  for  months. 

In  some  instances  the  lack  of  defined  processes  is  beyond 
the  program  or  project  manager's  control.  For  example,  an  IT 
system  may  need  to  be  compatible  with  other  applications 
being  developed  by  other  program  offices.  In  such  instances, 
coordination  between  agencies  is  required  at  the  Service 
level. 

Funding  for  Constant  Change 

DoD's  planning,  programming,  budgeting,  and  execution 
(PPBE)  process  is  another  element  that  does  not  function 
well  with  the  rapid  pace  of  technology  advancements.  Be¬ 
cause  the  rapid  pace  of  technology  improvements  cannot  be 
forecasted  or  planned,  IT  program  managers  are  left  with  the 
problem  of  identifying  funds  to  implement  necessary  infor¬ 
mation  technology  changes.  To  quote  Deputy  Secretary  of 
Defense  William  Lynn  during  an  interview  with  Government 
Executive  Magazine  and  noted  in  a  Nov.  12,  2009,  nextgov. 
com  article,  "The  iPhone  was  developed  in  less  time  than  it 
takes  for  DoD  to  budget  for  an  IT  program."  Also,  funding 
upgrades  created  because  of  a  newly  discovered  vulnerabil¬ 
ity  or  hacker  attacks  are  impossible  to  predict  two  to  five 
years  in  the  future.  With  no  management  reserves  allowed 
in  DoD,  that  poses  a  significant  challenge  for  those  respon¬ 
sible  for  managing  IT  programs— how  does  one  budget  for 
the  unknown  requirements?  Currently,  the  only  possible 
answer  is  to  continually  miss  budget  targets  and  escalate 
costs  to  higher  levels  within  the  government  and  for  Con¬ 
gress  to  provide  additional  funds  as  needed.  That  is  not  the 
most  desirable  approach  and  can  be  time  consuming.  The 
government  budgeting  process  requires  a  fundamental  shift 
to  be  more  flexible  and  responsive  in  order  to  accommodate 
fast-moving  programs. 

In  the  area  of  process  and  governance,  DoD  could  learn  from 
the  private  sector,  or  perhaps  it  needs  to  rely  on  industry  to 
bring  their  expertise  to  the  government.  There  are  gover¬ 
nance  models  for  IT  such  as  Control  Objectives  for  Infor¬ 
mation  and  related  Technology  (COBIT)  and  the  Informa¬ 
tion  Technology  Infrastructure  Library  (ITIL),  both  of  which 
recognize  the  need  for  flexibility.  Also,  corporations  are  in 
business  to  make  a  profit,  and  in  the  past  decade  or  so,  they 
have  realized  the  important  role  that  IT  plays  in  their  ability 
to  remain  competitive  in  the  marketplace.  Corporations  also 
have  concerns  about  technology  changes,  hackers  stealing 
corporate  sensitive  information,  budgets,  and  planning  capi¬ 
tal  investments.  Corporations  tend  to  have  an  IT  strategy 
that  is  in  alignment  with  their  goals  and  objectives. 


Change  Requires  Change 

Managing  the  rapid  rate  of  advancement  in  technology  in 
IT-intensive  programs  presents  many  new  situations  that 
have  never  been  encountered.  The  examples  cited  in  this 
article  are  only  a  small  set  of  the  challenges  associated  with 
the  acquisition  of  IT  and  can  be  difficult  to  convey  to  senior 
managers,  approval  authorities,  and  policymakers  who  lack 
familiarity  with  those  challenges  and  IT  in  general. 

A  vision  for  IT  is  needed  at  the  DoD  enterprise  level  that 
translates  to  a  Service  perspective  and  moves  down  to  the 
individual  program  office.  Working  toward  a  common  vi¬ 
sion,  a  new  acquisition  process  needs  to  be  flexible  enough 
to  anticipate  change.  Those  changes  lead  to  adjustments  in 
requirements  and  require  that  well-thought-out  processes 
be  in  place  prior  to  starting  an  IT-intensive  program.  Early  on 
before  contract  award,  consideration  for  how  the  changes 
will  be  managed,  tested,  and  implemented  need  to  be  taken 
into  account,  and  the  program  office  must  also  identify  key 
stakeholders  who  need  to  participate  in  the  decision-making 
process  at  the  working  level.  All  of  those  things  require  that 
the  program  manager  have  support  at  the  component  and 
DoD  levels  to  help  coordinate  and  establish  those  processes 
that  may  be  outside  of  his  or  her  control. 

The  PPBE  process  is  no  exception  to  the  need  for  a  more 
responsive  process.  Response  to  rapid  change  requires  flex¬ 
ibility  in  programming  and  budgeting.  Perhaps  a  different 
PPBE  process  or  a  capital  investment  budgeting  process 
needs  to  be  in  place  to  help  fund  the  changes.  An  example 
may  be  to  use  the  private  sector  model  where  the  budgeting 
process  is  in  alignment  with  an  overall  corporate  IT  objec¬ 
tive.  Objectives  are  budgeted  for  and  funded  by  annually 
updated  capital  spending  plans.  Because  the  PPBE  process 
is  not  more  accommodating  to  change,  it  will  continue  to 
create  challenges  for  IT  acquisition  programs  and  they  will 
remain  unresponsive  to  change  and  vulnerable  to  widely 
available  emerging  threats. 

Once  an  acquisition  process  has  been  developed,  then  IT- 
acquisition-specific  training  should  be  developed  and  pro¬ 
vided.  Program  managers  currently  must  attend  Defense 
Acquisition  University  courses  for  level  III  certification  in 
program  management.  Given  that  more  and  more  systems 
are  becoming  IT  intensive,  additional  coverage  for  managing 
those  programs  should  be  part  of  that  training. 

Most  important,  treating  IT  programs  in  an  "out  of  sight, 
out  of  mind"  manner  with  no  real  dedication  of  time  and 
attention  to  the  problems  is  not  the  answer  in  the  face  of 
changing  technology  and  adversity.  What  is  needed  now  is 
dedication  by  senior  government  officials  who  recognize  the 
issues  being  caused  by  the  current  processes  and  can  affect 
the  needed  change  in  those  processes. 


The  author  welcomes  comments  and  questions  and  can  be 
contacted  at  kathy.peake@dau.mil. 
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